With the introduction of S_ADDRESS_TYPE, it opens the way for
a simple address messaging plugin interface, to allows users to
introduce pluggable address sending mechanisms, which rely on
a particular address value.

For example we could introduce an SMS address type, which would
require a single attribute of PHONE_NO.

Each class would know before hand what S_ATTRIBUTE_TYPE's it
requires in order to facilitate sending the message.

The sending process would call the particular implementation
class, and provide a USER_ADDRESS sequence_number, for which
the implementation class, could then request the specific
user_addr_attribute's it requires.

For example the EMAIL class would request the EMAIL_ADDR
attribute for the provided sequence_number, and use that 
to send the message.

For the moment only plain text messages would be supported.

Integration of address types (other than EMAIL) would require
some serious thinking.  Because for instance, notifications of
overdue items could be sent via EMAIL, SMS or a Instant Messaging 
service (Such as JABBER).

So should we allow the user to specify their preferred
communication mechanism as part of the USER_ADDRESS record.

Then all messages sent from OpenDb would be routed to the
correct address type destination.

Should we have one USER_ADDRESS system_address_ind, or 
multiple indicators for the different types of messages, such
as:
	borrow.reminders
	borrow.reservations
	borrow.cancel
	borrow.checkin
	borrow.checkout
	site.broadcast
	item.owner_id.re (User clicks on Owner to send email about specific item)
	
Perhaps only borrow.reminders should be sent via SMS...

Should we add all these as indicators to the user_address table?

